http: avoid stream listeners on idle agent sockets#64004
Conversation
|
Review requested:
|
|
@nodejs/releasers unfortunately, we would need to backport this to node 22.x and 24.x to fix node-fetch@2. |
|
I'm sorry I should have caught this before shipping. |
Renegade334
left a comment
There was a problem hiding this comment.
Side-note: I had a cursory look for guidance on Node.js internals managing EventEmitter events on emitter-derived Node.js classes, and found none. My feeling is that we don't ordinarily consider changes related to internally-managed event listeners to be semver-major, even though they're publicly observable. Maybe we should elucidate what our stance is, and make it explicit in the EventEmitter documentation?
|
Fast-track has been requested by @Renegade334. Please 👍 to approve. |
Signed-off-by: Matteo Collina <hello@matteocollina.com>
8d8919c to
0d62f61
Compare
What I don't fully understand is why this wasn't released as |
|
Shipping a Node.js release is somewhat hard work. Node.js is a community of volunteers.
Because node-fetch is not part of https://github.com/nodejs/citgm. Given that it's essentially unmaintained (last release: 3 years ago), it fails the basic requirements to be there.
I'm sorry to disappoint you, but Node.js is a community of volunteers. There are no plans, as everyone here does their best. You can, as always, volunteer your time or resources to improve things. |
Fixes: #63989
The response-queue-poisoning guard added to idle
http.Agentsockets used a public'data'listener. That madenode-fetch@2observesocket.listenerCount('data') > 0during response close and report falseERR_STREAM_PREMATURE_CLOSEerrors.This changes the idle-socket guard to use the socket handle's internal
onreadhook while the socket is in the free pool, restoring the normal stream read callback when the socket is reused. The guard still destroys sockets that receive unsolicited data while idle, but it no longer adds public stream listeners.